home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 657 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.3 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: Re: XATTR structure for BIOS filesystem #2
  3. Date: Mon, 22 Nov 93 12:32:27 MET
  4. In-Reply-To: <9311220909.AA25289@hpbeo79.bbn.hp.com>; from "Claus Brod" at Nov 22, 93 10:09:22 am
  5.  
  6. > Not too bad an idea. I'd suggest the following "calling convention":
  7. >
  8. > - call datime in mode 0, store return value
  9. > - call datime in mode 2
  10. > - call datime in mode 0; compare with previous result; if the results
  11. >   differ, call datime in mode 1 with the old value
  12. >
  13. > This way, you make sure that even old drivers will not permanently
  14. > change access times because they don't know about mode 2 and 3.
  15.  
  16. That's right, but:
  17.  
  18. 1) You would then force "old" drivers to keep their creation time, which
  19. might be a good idea, but may be useless 'cause MiNT now returns the
  20. current time/date for it, at least if you call Fxattr() and not Fdatime(),
  21. so I doubt any driver itself, or literally any program uses this info so
  22. far, so you needn't expect any troubles if you don't do so, I think.
  23.  
  24. 2) (more general) Setting up an auxiliary FILEPTR in getxattr and filling it
  25. with some fake data already needs some time (and so far I've forgotten to
  26. take care of device drivers being responsable for more than one device, so
  27. this would involve yet more ops) plus 3 or 4 calls to fdatime... Well, it's
  28. not that I particulary dislike it, but I'm a _bit_ fanatic on speed, so I'd
  29. like to be at least sure there isn't a faster solution with the same
  30. properties.
  31.  
  32. The completely other idea (as discussed some days ago) could change the data
  33. itself by gaining access to its bios_file over (struct bios_file *)f->fc.index,
  34. only that for now it doesn't know an XATTR field exists. To be very clear:
  35. This mustn't be extra implemented, this is already there, so I may very well
  36. consider my own security thoughts being totally wasted and unfullfillable :-(
  37.  
  38. But this one would be quite faster for both sides.
  39.  
  40. But either method would take advantage if the kernelptr would not only
  41. provide time manipulating functions, but time values itself... :-)
  42.  
  43. Shall we vote which idea is better? ;-)
  44.  
  45. bye,
  46. TeSche
  47. -- 
  48. PS: If the above written looks weird, than that's because it probably IS.
  49. WhoDunnIt: Torsten Scherer (Schiller, TeSche...)
  50. Technical Faculty, University of Bielefeld, Germany (52'5"N 8'35"E)
  51. EMail: itschere@techfak.uni-bielefeld.de / tesche@dave.hrz.uni-bielefeld.de
  52.